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ABSTRACT 

Various techniques need to be combined to realize anony- 
mously authenticated communication. Cryptographic tools 
enable anonymous user authentication while anonymous com- 
munication protocols hide users' IP addresses from service 
providers. One simple approach for realizing anonymously 
authenticated communication is their simple combination, 
but this gives rise to another issue; how to build a secure 
channel. The current public key infrastructure cannot be 
used since the user's public key identifies the user. To cope 
with this issue, we propose a protocol that uses identity- 
based encryption for packet encryption without sacrificing 
anonymity, and group signature for anonymous user authen- 
tication. Communications in the protocol take place through 
proxy entities that conceal users' IP addresses from service 
providers. The underlying group signature is customized to 
meet our objective and improve its efficiency. We also intro- 
duce a proof-of-concept implementation to demonstrate the 
protocol's feasibility. We compare its performance to SSL 
communication and demonstrate its practicality, and con- 
clude that the protocol realizes secure, anonymous, and au- 
thenticated communication between users and service providers 
with practical performance. 
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1. INTRODUCTION 

Anonymitj_ is an important aspect of privacy, and sys- 
tems that provide services to anonymous users are currently 
a topic of keen interest. Such systems can provide services 
to users without revealing their identity. To date, a great 
deal of studies have been reported on [2], and many use 
cryptography as the important building block for construct- 
ing the systems, but these need further improvement be- 
fore they can be used for actual services. To realize secure, 
anonymous, and authenticated communication, these build- 
ing blocks need to collaborate with each other. 

1.1 Research Background 

Several cryptographic primitives providing anonymity have 
been proposed. Among them is group signature [_j], which 
enables a signer to anonymously prove signatures' validity. 
A group manager (GM) that has a pair of a group public 
key, gpk, and master secret key, msk, issues a secret signing 
key, ski, to a user Ui, which computes a group signature, a 
(on certain messages), using ski. No user-dependent value is 
required in the verification phase; a verifier verifies a using 
only the corresponding gpk. These approaches alone, how- 
ever, cannot guarantee anonymity when applied to online 
communication. For instance, let a signer compute a group 
signature and send it to a verifier. The verifier can anony- 
mously verify the signature's validity. However, there is a 
question of how to anonymously send the group signature 
to the verifier. Usually, a source IP address is included in a 
packet, and that reveals the identity of the sender, thus user 
anonymity is already infringed upon. The situation remains 
the same regardless of the primitives we implement so long 
as direct communication between a sender (signer, prover, 
etc) and a receiver (verifier, etc) is required. 

The user's IP address is naturally visible in the IP packets 
sent from the user, and it cannot simply be erased or forged 

x This paper considers sender/prover anonymity and does 
not consider recipient anonymity. 
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to enable bi-directional communication. One approach for 
this is using intermediate agents that send packets on be- 
half of the actual user terminal, and several such protocols 
have already been proposed [2], including Tor [5]. Never- 
theless, another issue arises in the question of how we can 
assure user's legitimacy. We need to discern legitimate and 
illegitimate users to restrict unauthorized access to the chan- 
nel. One might think that only end-to-end authentication is 
needed, but it is hard to authenticate users without identi- 
fying them. For instance, a server needs to send a response 
code to a user in basic authentication and the user needs to 
return a user ID and password. That is, the server needs 
to identify the user. Moreover, it seems to be hard to send 
a certain message back from the server to a user since the 
corresponding source IP address is generally required. Au- 
thentication by an intermediate agent (as in Tor [5]) might 
be a solution to these problems. The agent can authenticate 
a user and can hide the user's source IP address from the 
server. That notwithstanding, we still need to know how the 
server can directly authenticate end users. 

A simple approach to the anonymous authentication prob- 
lems is just combining both cryptographic primitives and 
anonymous communication protocols as follows. Let a user 
compute an anonymously-authenticated token (e.g., group 
signature), and send it to a server via an anonymous chan- 
nel (e.g., using Tor). Then, the server can directly authen- 
ticate the user without compromising anonymity. However, 
another problem arises is how we can establish a secure chan- 
nel (i.e., flowed data is encrypted). If the server uses a user's 
public key (certified by a trusted Certificate Authority (CA) 
in a public key infrastructure (PKI)), then server identifies 
the user, since a certificate contains information on the key 
holder. The same problem arises even if symmetric key en- 
cryption is used. Assume that the server tries to exchange a 
secret key with an end user. Since the server does not know 
who the actual end user is, the server does not know the 
user's public key for running a key exchange protocol. 

1.2 Our Contribution 

We propose a protocol that realizes secure, anonymous, 
and authenticated communication. The proposed proto- 
col uses identity-based encryption (IBE) to encrypt content 
without identifying key holderfl It can set arbitrary values 
on public keys, thus it can enable a user to select a tem- 
porary ID for each session, which the server can use as a 
public key. It also uses group signature for anonymous user 
authentication. Communications in the protocol take place 
through proxy entities that conceal users' IP addresses from 
service providers (SPs). 

This paper gives the framework of the proposed protocol, 
gives a formal model and security definitions of the pro- 
posed protocol, points out the needlessness of the group sig- 
nature's open capability for our usage, and then proposes 
an open-free variant of the Furukawa-Imai group signature 
scheme [T3]- The modification can reduce its signature size 

2 The conventional public key encryption (PKE) with certain 
non-interactive zero-knowledge (NIZK) proofs may also be 
applicable, where a user chooses a temporary public key for 
each session, and makes a NIZK proof of the correspond- 
ing secret key. We do not consider this construction any- 
more since the NIZK proof must be constructed from scratch 
by considering algebraic structures of the underlying PKE 
scheme, and this may lead to some difficulty of its imple- 
mentation. 



by 50% compared to the original scheme. Note that if some- 
one needs to identify an illegitimate user, we can add such 
a mechanism without relying on cryptographic techniques; 
e.g., an IP address managed by the proxy. 

We demonstrate the feasibility and practicality of the pro- 
posed protocol by introducing our proof-of-concept imple- 
mentation. The implementation uses the modified group 
signature scheme mentioned above. It also uses the Boneh- 
Franklin IBE scheme [9] for its underlying IBE scheme. 

Note that, our protocol in this paper focuses on encrypted 
communication from the SP to users. It can easily be ex- 
tended to interactive secure communication since SP is not 
anonymous to users and each user thus can simply use SP's 
public key for building a secure channel. 

1.3 Related Work 

There exist similar attempts to our approach. Sudarsono 
et al. [21] has considered an anonymous IEEE802.1X authen- 
tication system by using a group signature scheme. They use 
group signatures as the client's digital certificate. The means 
of sending such certificates over IP networks was, however, 
outside its scope. Lee et al. [16] proposed an anonymous 
subscription service, called Anon-pass. Their construction 
methodology is similar to group signatures, wherein a user 
proves the possession of signatures using zero-knowledge proofs. 
Though Anon-pass does not consider end-to-end secure (en- 
crypted) communication, our protocol does. 

Gilad and Herzberg 14 also considered how to distribute 
public keys using an anonymous service. They consider two 
peers, a querier and a responder. The querier specifies a 
random ephemeral public key that is not certified by the 
CA, and sends a query containing this public key to a re- 
sponder via an anonymous service, like Tor. The responder 
replies with a response message encrypted by the (anony- 
mous) querier's ephemeral public key. However, a respon- 
der cannot check whether a public key is a valid key or a 
random value since this scheme gives no certification of the 
public key, and moreover the responder cannot detect even 
if the pubic key is replaced by an attacker. Moreover, no 
anonymous user authentication is considered in the Gilad- 
Herzberg system. In our protocol, the SP can be convinced 
that a public key (i.e., a temporary ID) will work, since ar- 
bitrary values can be public keys in IBE systems. Moreover, 
since a temporary ID is signed by group signature, we can 
prevent the key replacement attack and can achieve anony- 
mous user authentication, simultaneously. 

Proxy re-encryption (PRE) (e.g., [18]) is another candi- 
date. In our context, first users compute re-encryption keys 
using their secret key and the SP public key, and the SP 
only computes ciphertext using its own public key. Then, 
the proxy can re-encrypt ciphertexts. However, the proxy 
needs to manage all re-encryption keys, and therefore it is 
difficult to assume that no private information is infringed 
on even if the proxy is corrupted after the communication. 
Moreover, there is a possibility that other user may decrypt 
unexpected ciphertexts, since the proxy manages many re- 
encryption keys (from the SP to each user). It is undesirable 
to generate re-encryption keys that can be used in an unex- 
pected manner, even if the proxy is modeled as an honest- 
but-curious entity and always follows the protocol. In our 
protocol no unexpected user (including the proxy) can de- 
crypt ciphertexts, since a unique temporary ID is assigned 
for each user and each session. Note that the key escrow 
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formation is infringed on even if the proxy is corrupted after 
the communication. Note that Figure [1] explains one-pass 
communication. The proxy can reuse the information of the 
pair (TempID, Adr src ) of a session so long as the session is 
alive, but it removes the information from its registry once 
the session is closed. In either case, the proxy immediately 
deletes the corresponding pair (TempID, Adr src ) after the ses- 
sion. Moreover, we can easily extend one-proxy setting to 
multi-proxy setting, since all the proxy has to do is (1) man- 
age (TempID, Adr src ), and (2) forwarding [a, TempID) to the 
next. The above framework is embodied as a concrete pro- 
tocol in the following section. 



Figure 1: Framework of the Proposed Protocol 

problem happens as an outcome of IBE, where key gener- 
ation center (KGC) can decrypt all ciphertexts. However, 
KGC is modeled as a trusted third party, whereas it is dif- 
ficult to fully trust all proxies involved in the systems. 

2. FRAMEWORK 

Figure [T] depicts the framework of the proposed protocol, 
which has five roles; User, Proxy, Service Provider, GM, and 
KGC. A User wishes to communicate with an SP without 
revealing its identity. The Proxy assists communication be- 
tween a User and SP by relaying packets without revealing 
the User's IP address. We assume that it is honest-but- 
curious. The SP provides services to Users, but wishes to 
authenticate them. It does not care about their identities 
but needs to confirm whether the user accessing it is legit- 
imate. The GM manages a group key and issuer key, and 
issues a signing key for a user that is used for generating 
an anonymously-authenticated token. We assume that the 
GM suitably authenticates a user before issuing the signing 
key. The KGC generates a decryption key for a user. We 
assume that the KGC suitably authenticates a user before 
issuing the decryption key. 

These roles need to collaborate with each other to realize 
the proposed secure anonymous authentication. Their inter- 
action sequence is as follows. (1) A user (whose IP address 
is Adr src ) chooses a temporary ID TempID, (2) computes 
a group signature cr on TempID, and (3) sends (cr, TempID) 
to the proxy. (4) The proxy associates Adr src with this 
temporary ID, and (5) forwards (cr, TempID) to the SP. (6) 
The SP can directly authenticate the users by verifying the 
group signature without compromising anonymous commu- 
nications. (7) If the user is successfully verified, the SP 
encrypts content using TempID as the public key of IBE; 
otherwise it returns _L. Here, we apply an IBE's property 
to establish a secure channel between the SP and an anony- 
mous user, where arbitrary values can be a public key, and 
a ciphertext can be independently computed with the gen- 
eration of the corresponding decryption kej0. (8) The SP 
sends this IBE ciphertext to the proxy, which again (9) for- 
wards it to the corresponding user. (10) Finally, the user de- 
crypts the IBE ciphertext using the corresponding decryp- 
tion key issued by the KGC. After relaying the (mutual) 
communication, the proxy immediately deletes the corre- 
sponding pair of (TempID, Adr src ). Therefore, no private in- 

3 This property is used in timed-release encryption [TT] con- 
text, where an encryptor can control when ciphertexts will 
be decrypted. 



3. AUTHENTICATION PROTOCOL 

This section proposes a secure anonymous authentication 
protocol. It first defines the syntax of the protocol, and then 
gives its construction. We consider a scenario in which an 
SP is modeled as a server, which provides a service only for 
a legitimate user. That is, we can assume that the GM has 
authenticated a user before issuing a signing key, and the 
SP can judge that the user who can generate a valid group 
signature is a legitimate user. 

3.1 Syntax and Security Definitions 

Let XV and M be an identity space and message space, 
respectively, and Adr src , Adr proxy , and Adr ds t stand for IP 
address of User, Proxy, and SP, respectively. For a set X 

$ 

and an element x £ X, x <— X means that x is randomly 
chosen from X. 

Definition 3.1 (Syntax of The Protocol). 

GM. Setup / This probabilistic algorithm takes as input the 
security parameter A, and outputs a group public key 
gpk and an issuer key ik. 

KGC. Setup : This probabilistic algorithm takes as input the 
security parameter A, and outputs a public key params 
and a master secret key msk. 

Join / This probabilistic algorithm takes as input gpk and 
ik, and outputs a signing key sk. 

UserKeyGen : This (possibly) probabilistic algorithm takes 
as input params, msk, and an (possibly temporary) 
identity TempID 6 ID, and outputs a decryption key 

c/&TempID • 

SendRequest : This probabilistic algorithm takes as input 
gpk, sk, TempID, a source IP address Adr src , a destina- 
tion IP address Adr as t , and a proxy IP address Adr proxy , 
and send a token a, TempID and Adr ds t to the proxy 
whose IP address is Adr pr0 xy . 

Relay Request : This deterministic algorithm takes as input 
Adr src , Adr ds t, an ID/IP table Tbl, a, and TempID, and 
relays a pair (a, TempID) and Adr proxy to the destina- 
tion SP whose IP address is Adrdst . Moreover, append 
(TempID, Adr src ) to Tbl. 

ValidityCheck : This deterministic algorithm takes as input 
gpk, a , and TempID, and outputs 1 if a is valid, and 0, 
otherwise. 

SendContent ; This probabilistic algorithm takes as input 
gpk, a, TempID, a content to be sent M £ M, and 
Adr proxy, computes a ciphertext C if the token a is 
valid, and sends C to the proxy whose IP address is 
Adr proxy . Otherwise, if a is invalid, then return _L. 
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RelayContent : This deterministic algorithm takes as in- 
put C and Tbl, and relays C to a user whose IP ad- 
dress is Adr src contained in Tbl. Moreover, remove 
(TempID, Adr src ) from Tbl. We assume that the proxy 
can decide the corresponding source IP address to be 
relayed by C0. 

GetContent : This deterministic algorithm takes as input C 
and dfciempiD, and return M . 

Next, we give formal security definitions as follows. First, 
we define correctness that guarantees a is valid and a user 
always can obtain the corresponding content if all values are 
honestly generated according to the algorithms. 

Definition 3.2 (Correctness). For all (gpk,ik) 
GM.Setup(l A ), (params,msk) KGC.Setup(l A ), sk <— Join(< 
TempID G XV, M G M, and (Adr src , Adr dst , Adr proxy ), 

Pr[M <- GetContent^RelayContent(C,Tbl), 

UserKeyGen (param, msk, TempID)^] = 1, and 

Pr[l <- ValidityCheck(3pfc,o-, TempID) = 1] = 1 

where (a, TempID, Adr dst ) <— SendRequest(gpfc, sk, TempID, 
Adr src , Adr dst , Adr p roxy ) , (o, TempID, Adr proxy ) <— RelayRequest 
(Adr src , Adrdst, Tbl, a, TempID) , and C SendContent(<;pfc, o, 
TempID, M, Adr proxy ). 

Next, we define anonymity, semantic security, and unforge- 
ability as follows. One session is defined as sequences of al- 
gorithm executions from SendRequest to GetContent, where 
SendRequest — ¥ RelayRequest — > SendContent — > RelayContent 
GetContent. Anonymity guarantees that no adversary A 
who is allowed to communicate with the proxy (but is not 
allowed to know Adr src ) can distinguish whether the users of 
two different sessions are the same or not. In this game, A is 
modeled as a malicious SP. Moreover, we care about signing 
key exposure, where A can obtain signing keys. In addition 
to this, we give msk to A in order to guarantee that the 
KGC ability has nothing to right for identifying the usefl 

Definition 3.3 (Anonymity). 

1. The challenger C runs (gpk,ik) <— GM.Setup(l A ) and 
(params,msk) -s— KGC.Setup(l A ), and computes two 
signing keys sko,ski <— Jo\n(gpk, ik), and gives gpk, 
sko, ski, and (params,msk) to an adversary A. More- 
over, C initializes Tbl := 0. 

2. A is allowed to issue the SendRequest query (i, TempID) 
€ {0,1} x TT>. C runs SendRequest(gpfc, skt, TempID, 
Adr src , Adrdst , Adr proxy ), and returns a (generated via 
the SendRequest algorithm) to A. 

3. A is allowed to issue the RelayRequest query (o, TempID). 
C runs RelayRequest(Adr sr c, Adrdst, Tbl, ct, TempID) and 
updates Tbl. 

4- A is allowed to issue the RelayContent query C . C runs 
RelayContent(C, Tbl) , and updates Tbl. 

4 For example, port numbers can be used for identifying the 

sessions. It's up to the proxy in our implementation. 

5 Note that we exclude the trivial case that KGC is offered 

to generate a decryption key of TempID from a user whose IP 

address is Adr sr c , and observes that the transcript containing 

TempID. 



5. A sends TempID* G TV to C. C flips a coin b <— {0, 1}, 
and runs (a*, TempID*, Adrdst) <— SendRequest(i?pfc, 

sk b , TempID*, Adr S rc, Adr ds t , Adr pr o X y ) and (a*, TempID*, 
Adrproxy) RelayRequest(Adr sr c, Adr ds t, Tbl, a*, TempID*). 
A returns an arbitrary C toC. C runs C RelayContent(C, 
Tbl). Note that A can know the transcript of these 
algorithms executed by C: (a*, TempID*, Adrdst), (c*, 
TempID*, Adrproxy), and C. A outputs b' G {0, 1}. 

The protocol is said to have anonymity if Ad\/p"° n A (\) := 
| Pr[6 = b'] — 1/2| is negligible in A. 

Next, we define semantic security which guarantees that no 
information of content M is revealed from the transcripts 
of algorithms. In this game, an adversary A is modeled as 
; ^^nalicious proxy. Moreover, A is allowed to obtain ik in 
order to guarantee that no information of M is revealed even 
from the GM's viewpoint. 

Definition 3.4 (Semantic Security). 

1. The challenger C runs (gpk,ik) GM.Setup(l A ) and 
(params,msk) <— KGC.Setup(l A ), and gives gpk, ik, 
and params to an adversary A. 

2. A is allowed to issue the UserKeyGen query TempID G 
TV. C runs UserKeyGen (params, msk, TempID) and 
returns dfciempiD ■ 

3. A sends TempID* G TV, Mq,M* G M and sk* to C 
as his choice, where TempID* has not been sent as a 

UserKeyGen query. C flips a coin b <— {0, 1}, runs 
SendRequest(gpfc, sk* , TempID*, Adr sr c, Adr ds t, Adr pr o X y) 

and C* <— SendContent((;pfc, a, TempID, M£ , Adr pr0 xy), 
and sends (a, TempID*, Adr ds t) and C* to A. 

4- A is allowed to issue the UserKeyGen query TempID G 
TV where TempID ^ TempID*. C runs UserKeyGen (params, 
msk, TempID) and returns dkj emp iD- 

5. Finally, A outputs b' G {0, 1}. 

The protocol is said to have semantic security i/AdVp S ro ^(A) := 
| Pr[6 = 6'] — 1/2| is negligible in A. 

Finally, we define unforgeability which guarantees that no 
adversary A who does not have a signing key will be accepted 
by the ValidityCheck algorithm. In this game, A is modeled 
as a malicious user. Moreover, A is allowed to obtain msk 
in order to guarantee that nobody can be accepted by SP 
even by KGC. 

Definition 3.5 (Unforgeability). 

1. The challenger C runs (gpk,ik) GM.Setup(l A ) and 
(params, msk) <— KGC.Setup(l A ), and gives gpk and 
params to an adversary A. Moreover, C initializes 
5 = 0. 

2. A is allowed to issue the SendRequest query (i, TempID). 

If ski has not been generated, then C runs ski <— Join(gpfc, ik) 
and preserves ski. C runs SendRequest(gpfc, ski, TempID, 
Adr S rc, Adr ds t, Adrproxy), and sends a to A. Moreover, 
C appends (a, TempID) to S. 

3. Finally, A outputs (a*, TempID*). We say that A wins 
if(c*, TempID*) 0 S and ValidityCheck(i?pfc, a*, TempID*) 
= 1. 
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The protocol is said to have unforgeability if AdVp f ro A (X) := 
Pr[A wins] is negligible in X. 

We say that a protocol is called secure anonymous authenti- 
cation protocol if the protocol is correct and has anonymity, 
semantic security, and unforgeability. 

3.2 Protocol Construction 

Here, we give our proposed protocol construction. First, 
we define the syntax of building blocks - IBE and open-free 
group signature - as follows: 

An IBE scheme XB£ consists of four algorithms: i.e., 
(IBE. Setup, Extract, IBE. Enc, IBE. Dec). Let TV and M be 
an identity space and message space, respectively. 

Definition 3.6 (Syntax of IBE [§]). 

IBE. Setup: This algorithm takes as input the security param- 
eter X, and outputs a public key params and a master 
secret key msk. 

Extract: This algorithm takes as input params, msk, and 
an identity ID £ TV, and outputs a decryption key 
dkio- 

IBE. Enc: This algorithm takes as input params, ID, and a 
message M £ M, and outputs a ciphertext Cibe- 

IBE. Dec: This algorithm takes as input params, Cibe, and 
dkio, and outputs M. 

We require the following correctness property: for all (params, 
msk) i- IBE.Setup(l A ), all ID and all M, Pr[IBE.Dec(params, 
IBE. Enc(params, ID, M), Extract(params, msk, ID)) = M] = 
1 holds. 

An open-free group signature scheme QS consists of four 
algorithms: (GS. Setup, Join, Sign, Verify as follows: 



Construction 3.1 (Proposed Protocol). 

Run (gpk,ik) <— GS.Setup(l A ), and output (gpk, 



IBE.Setup(l A ), and out- 



GM. Setup 

ik). 

KGC. Setup : Run (params, msk) 
put (params, msk). 

Join : Run sk GSJoin(i?pfc, ik), and output sk. 

UserKeyGen : Rundkrempio Extract(params, msk, TempID), 
and output dfciempiD- 

SendRequest ; Choose TempID <s— TV. Run a <— S\gn(gpk, sk, 
TempID), and send (a, TempID, Adr dst ) to the proxy whose 
IP address is Adr proxy . 

RelayRequest : Append (TempID, Adr src ) to Tbl, and relays 
a pair (a, TempID) and Adr proxy to the destination SP 
whose IP address is Adr ds t ■ 

ValidityCheck : Output 1 if Verify (gpk, a, TempID) = 1, and 

0, otherwise. 

SendContent : Output J_ if ValidityCheck(i?pfc, a, TempID) = 
0. Otherwise, run Cibe <— IBE. Enc(params, TempID, 
M), and send Cibe to the proxy whose IP address is 
Adr D roxv • 



RelayContent : Relay Cibe to a user whose IP address is 
Adr src contained in Tbl. Moreover, remove (TempID, 
Adr src ) from Tbl. 

GetContent ; Output the result of \BE.Dec(params,CiBE, 



dh 



TempID ) 



Note that our the above construction only considers one- 
proxy setting, and therefore no anonymity is guaranteed 
Definition 3.7 (Syntax of Open-Free Group SiGNATURg-}, m the viewpoint of the Proxy, since the Proxy directly 

relays communications between the User and SP. Note that 



GS. Setup: This algorithm takes as input the security param- 
eter X, and outputs a group public key gpk and an is- 
suer key ik. 

GS.Join: This algorithm takes as input gpk and ik (from 
CM), and a user is obtained a signing key sk. 

Sign: This algorithm takes as input gpk, a signing key sk, 
and a message M, and outputs a group signature a. 

Verify: This algorithm takes as input gpk, a, and M , and 
outputs 1 if a is a valid signature on M , and 0 other- 
wise. 

We require the following correctness property: for all (gpk, ik) 
<— GS.Setup(l A ) and sk <— GS Join (gpk, ik), Pr[Verify(gpfc, 
S\gn(gpk, sk, M), M) = 1] = 1 holds. 

Next, we give our proposed construction. In this construc- 
tion, a signed message of the underlying group signature is 
TempID which is also regarded as a public key of the under- 
lying IBE. 

6 This new primitive is a kind of dynamic group signature, 
where a new member can join the system even after the 
setup phase. Note that, additional two algorithms, Open 
and Judge, are usually contained in dynamic group signa- 
tures (e.g. [7j). The Judge algorithm checks a proof output 
by the Open algorithm, whether the Open algorithm is cor- 
rectly executed or not. Obviously, the Judge algorithm is 
meaningless in the open-free variant. 



this situation does not contradict our definition of anonymity 
(Def. I3.3[) . We can simply extend this protocol to a multi- 
proxy setting, where each Proxy relays (a, TempID) or Cibe 
between the previous Proxy and the next Proxy. Then, 
anonymity is guaranteed even from the Proxies' point of 
view unless all Proxies collude with each other. 



4. GROUP SIGNATURE 

The proposed secure anonymous authentication protocol 
uses a group signature scheme as its fundamental compo- 
nent. Though arbitrary group signature schemes could be 
used (i.e., by ignoring open functionality), it is beneficial to 
remove unnecessary functionality and improve performance 
efficiency, thus the proposed protocol in Section 13.21 uses a 
group signature without open functionality. We call this an 
open-free group signaturqj. This section defines the security 



of such signatures. 



7 A difference between ring signature [20] and open-free 
group signature is as follows. In ring signature schemes, 
a signer chooses a set of other members, and signs on behalf 
of the group of users. The anonymity of the signer cannot be 
revoked in contrast to group signature schemes. However, 
a signer needs to involve/choose other members when the 
signer signs, and therefore needs to know other members. 
This does not match our setting. 
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4.1 Defining Open-free Group Signature 

In this section, we redefine the security definitions of the 
Furukawa-Imai group signature scheme, anonymity, trace- 
ability, and non-frameability, to match the open- free variant. 
Anonymity guarantees that no adversary A can distinguish 
whether two signers of group signatures are the same or 
not, even if A has the corresponding signing keys. Usually, 
there are two kind of anonymity, CPA-anonymity and CCA- 
anonymity. In CCA-anonymity, A is allowed to issue open 
queries, where A sends (a,M), and is given the result of 
the Open algorithm. Meanwhile, we do not have to consider 
these differences due to the open-free property. 

Definition 4.1 (Anonymity). 

1. An adversary A with the security parameter A sends 
gpk, sko, sk\, and M to the challenger C. 



2. C chooses b 4— {0, 1}, computes a* 
and sends a* to A. 

3. A outputs a bit b' G {0, 1}. 



S\gn(gpk,sk b ,M), 



An open-free group signature QS is said to have anonymity 
if Adv^^(A) := | Pr[6 = 6'] - 1/2| is negligible in A. 

Next, we redefine traceability. In usual definition, Trace- 
ability guarantees that no adversary A can produce a valid- 
but-untraceable group signature, that is, the Open algorithm 
cannot identify the corresponding signer though the Verify 
algorithm outputs 1. However, in the open- free variant, this 
definition is meaningless. So, we define unforgeability here 
instead of traceability, where no adversary A can produce a 
valid group signature without knowing a signing key. 



and 



Definition 4.2 (Unforgeability). 

1. The challenger C runs (gpk,ik) 4- GS.Setup(l A ) 
gives gpk to an adversary A. 

2. A is allowed to issue the signing query (M,i). If a 
user Ui has not been joined to the system, then C runs 
the GSJoin algorithm, computes ski, and returns a 4- 
S\gn(gpk, ski, M) to A. If Ui has been joined to the 
system, then C returns a 4— S\gn(gpk, ski, M) to A. 
Moreover, C appends (a,M) into the list S. 

3. Finally, A outputs (a*,M*). We say that A wins if 
Verify (gpk, a*, M*) = 1 holds and (a*,M*) 0 S. 

An open-free group signature QS is said to have unforgeabil- 
ity i/AdvgJs _^(A) := Pr[A wins] is negligible in A. 

Finally, we revisit non-frameability. Non-frameability guar- 
antees that no adversary A can produce a valid group sig- 
nature whose open result is an honest (i.e., uncorrupted by 
A) user (say U). Obviously, this definition is meaningless 
in the open-free variant, and therefore we do not consider 
non-frameability. 

Note that in order to achieve non-frameability in the orig- 
inal scheme, a user chooses a secret key usk, and is obtained 
its signing key sk by executing the GSJoin algorithm with 
GM. What is critical, GM cannot know usk itself (but can 
convince that the user knows usk by using zero-knowledge 
proofs). In other words, we can remove a secret key usk 
from the syntax of group signature unless non-frameability 
is required. This is is the reason why we do not require any 
secret key of users as input of the GSJoin algorithm, and 
the GSJoin algorithm can be a non-interactive algorithm. 



4.2 Building Open-Free Group Signature 

Our group signature scheme modifies the Furukawa-Imai 
group signature In the Furukawa-Imai scheme, a user 

certificate issued by the GM is a short signature [8] . The user 
proves the possession of the certificate by NIZK proofs which 
are constructed via the Fiat- Shamir conversion [T2 . For 
implementing the Open algorithm, an ElGamal-type double 
encryption is used over a decisional Diffie-Hellman (DDH)- 
hard group (in addition to bilinear groups). In our open- 
free scheme, the DDH-hard group can be removed. Other 
part is the same as that of the original Furukawa-Imai group 
signature scheme. 

Note that, a simple construction, where for one signature 
verification/signing key pair (VK,SK), each group member 
shares SK, can also be seen as an open-free group signature 
scheme. However, this simple construction never realizes the 
revocation functionality [17| . Towards constructing a revo- 
cable open-free group signature scheme, we newly construct 
an open-free group signature scheme. 

Construction 4.1 (Proposed Open-Free Group Signature). 

GS. Setup: Let (Gi,G2,Gt) be a bilinear group with prime 
order p, where (g\) = Gi, (52) = G2, and e : Gi x 

G2 — ► Gt be a bilinear ma?Q. Choose 7 4— Z PJ and 

h 4— Gi, and compute W = g%- Output gpk = (Gi, G2, Gt, e, gi, gi, 
andik = 7, where H3 : {0, 1}* ^TL V is a hash function 
modeled as a random oracle. 



compute At 
Ai). 



GSJoin: For a user Ui, choose Xi,yi 4- Z p , 
1 

{gih~ Vi ) 1+:c i , and output ski = (xi,yi, 

Sign: Let sk = (x,y,A). Choose j3 4- Z p , set S — f3x — 

y, and compute T = Ah 13 . Choose r x ,r$,rp 4— 1 V , 
and compute R = e(h, g 2 ) rs e(h, W) rf3 /e(T, g 2 ) rx , c = 
H 3 (gpk,T,R,M), s x = r x + cx, s s = r 5 + cS, and 
s p — r fi + c/3, and output a — (T, c, s x , s$, sp). 

Verify: Compute R' = ^hS^^pll (fg^l) ~\ and out- 
put 1 if c = H2,{gpk,T, R' , M) holds, and 0 otherwise. 

Compared to the original Furukawa-Imai scheme, we can 
reduce three DDH-hard group elements and three Z p ele- 
ments. Accordingly, we can reduce the size of signature by 
50% compared to the original Furukawa-Imai group signa- 
ture scheme. 

5. IMPLEMENTATION AND DISCUSSION 
5.1 Analysis on Proposed Protocol 

We can prove that our proposed protocol is secure if the 
underlying IBE scheme is IND-ID-CPA secure (like the Boneh- 
Franklin IBE scheme [5]) and the underlying group signa- 
ture scheme is anonymous and unforgeable. We only give a 
sketch of proof of anonymity (other theorems can be simi- 
larly proved) here and omit the full proofs of the following 
theorems due to the page limitation. 

Theorem 5.1. Our protocol is anonymous if the under- 
lying group signature scheme is anonymous. 

8 We require bilinearity: for all a,b G Z p , e^J,^) — 
e(si,ff2) ab = e(g\,g%), and non-degeneracy: e(gi,g 2 ) / le r , 
where 1g t is the identity element in Gt- 
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Proof (Sketch). Let A be an adversary who can break 
anonymity of our protocol. Then, we can construct an al- 
gorithm B that breaks anonymity of the underlying group 
signature scheme as follow. Let C be the challenger of the un- 
derlying group signature. B generates gpk, sko, and ski, and 
generates all IBE-related values. Then B gives (gpk, sko, ski , 
params,msk) to A. In the challenge phase, B gets TempID* 
from A, forwards it to C, and gets a* from C. B uses a* 
as the output of the SendRequest algorithm, and similarly 
simulates other algorithms. A outputs b' and B also outputs 
b' as the guessing bit. Then, B can break anonymity of the 
group signature with the same advantage of A. This contra- 
dicts that the underlying group signature is anonymous. □ 

Theorem 5.2. Our protocol ts semantic secure if the un- 
rig IBE scheme is IND-ID-CPA secure. 



Theorem 5.3. Our protocol is unforgeable if the under- 
group signature scheme is unforgeable. 

5.2 Analysis on Group Signature 

The remaining part is to show that the proposed open-free 
group signature scheme is anonymous and unforgeable. The 
proposed open-free group signature scheme is constructed 
from an (honest-verifier) zero-knowledge proof of knowledge 
by using the Fiat-Shamir conversion [12]. First, we explain 
the original proof of knowledge protocol as follows. A prover 
computes (T,R), and sends it to a verifier. The verifier 
sends a challenge value c to the prover. The prover com- 
putes (s x , Ss, sp), and sends it to the verifier. The verifier 
checks whether the verification equation holds or not. Next, 
we show that this 3-move protocol is zero-knowledge (this 
immediately leads to anonymity). The simulator chooses 

A f- G and (3 «— Z p , and computes T = Ag±. Note that j3 is 
chosen uniformly random. Therefore, T generated from the 
simulator is drawn from a distribution that is indistinguish- 
able from the distribution output by any particular prover. 

$ 

For T £ G, the simulator chooses c, s x , sg, sp «— Z p , and 
computes R = -MhSzTM^f^ Then the tran- 

script (T, R, c, s x ,ss,S/3) here is indistinguishable from tran- 
scripts of the actual protocol. 

Next, we show that the protocol is a proof of knowledge. 
That is, we show there exists an extractor that can extract 
a SDH pair from (T, R, c, s x ,ss,sp) and (T, R, c' ,s' x ,s' s , s'p), 
where c 7^ c' and both transcripts satisfy the verification 

(sx-s^)(s,3-Sg)-(s5-Sa)(c-c') 

(c-c') 2 ' 

« 

holds. 



equation. Set x 



y 



and p~ tEZlJL. Then, 4^ 

c— c' ' e{g 1 ,g 2 ) 



e(h,g 2 f 5l - v e(h,W)f 3 



Therefore, for A = T/hP, e(A,g*W) = e(gi, g 2 )e(h, g 2 )' s 
holds. That is, (x, y, A) can be extracted. This immediately 
leads to unforgeability. We omit the formal proof since this 
is similar as that of the original Furukawa-Imai scheme. 

5.3 Prototype 

This section introduces a prototype that implements the 
proposed protocol and evaluates its performance to demon- 
strate the feasibility and practicality of the protocol. 

5.3.1 Implementation 

We built the User and SP modules by using C language 
(GCC version 4.2.1). We also used the TEPLA library g] for 
implementing the Boneh- Franklin IBE scheme and our open- 
free group signature scheme. This library supports optimal 



Ate pairings over Barreto-Naehrig (BN) elliptic curves [6] 
with 254-bit prime order and the corresponding embedded 
degree is 12. This enables 128-bit security. We used Sim- 
pleproxy [3] for the Proxy module. 

Three types of communication sequences are implemented, 
i.e., User-GM, User-KGC, and User-Proxy-SP, and each of 
the sequence runs the modules defined in Section [3.21 The 
User-GM sequence begins with the Join module, which com- 
municates with the GM. The GM then computes the signing 
key sk, and returns it to the User. The User-KGC sequence 
begins with the UserKeyGen module, which communicates 
with the KGC. The User sends TempID to the KGC, and 
the KGC then computes the decryption key dfc T empiD, and 
returns it to the User. The User-Proxy-SP sequence begins 
with the SendRequest module that sends a group signature 
and TempID. Upon receiving them, the Proxy runs Relay Re- 
quest module that forwards them to the SP. It then runs Va- 
lidityCheck module and SendContent module that returns 
an IBE ciphertext to the Proxy, which forwards that to the 
User. The User then runs GetContent module that decrypts 
the IBE ciphertext by using the corresponding dfc Te mpiD. 

Note that the User-GM sequence needs to be run before 
User-Proxy-SP sequence starts. Likewise, the User-KGC 
and User-Proxy-SP sequences are run in parallel, though 
the User-KGC procedure needs to be completed before User- 
Proxy-SP procedure's GetContent module is run. 



User Proxy] 5 

T group signature 

SendRequest (h ttp write) andTem P ID > gmup signature 

RelayRequest (http get) I a " dTem P ID , 



ValidityCheck 



IBE ciphertext 



IBE ciphertext 



RelayContent (http send) 



SendContent (http send) 



GetContent (http read) 

Figure 2: Sequences for User-Proxy-SP 

5.3.2 Performance Measurement 

An environment for performance evaluation of the pro- 
posed protocol was prepared. We used an Apple MacBookPro 
15inch mid 2010 (processor: 2.8GHz Intel Core i7, Mem- 
ory: 8GB, 1067 MHz DDR3, Darwin Kernel Version 12.4.0), 
and prepared two VMs by using VMware Fusion 5.0.3. We 
assigned the roles of the User to the MacOS the roles of 
the Proxy and SP on the VMs. For the Proxy, the VM 
ran FreeBSD amd64 9.1-RELEASE with one processor and 
256MB of memory, and for the SP, VM ran CentOS 5.9 
x86_64 with one processor and 512MB of memory. 

Here, we show that our protocol is feasible by showing 
the running time of algorithms and total running time of 
one session are msec order. First, we show the running time 
of one session (User— >Proxy— »SP— ►Proxy— s>User) in the fol- 
lowing cases: (1) HTTP communications (i.e., without any 
cryptographic operations), (2) SSL communications, and (3) 
our protocol in Table [1] To measure the running time of the 
SSL communication, we use the s_server/s_time command 
of the OpenSSL library (ver. l.O.le) [J. We use DHE-RSA- 

?e^l§MMaFfe Mtog^mMW pTOclMg W 
tions. This inefficiency is due to the pairing computation 
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Table 1: Running Time (one session) 



Scheme 


Time(msec) 


Cryptographic Operations 


None 


4.714 




SSL 


12.897 


Enc/Auth 


Ours 


624.743 


Erie/ Anon. Auth 



which is not required in usual public key encryption, digital 
signature, and authentication (these are used in SSL). Nev- 
ertheless, it is particularly worth noting that our running 
time still fits inside millisecond order, and our protocol even 
supports secure, anonymous, and authenticated communi- 
cation, simultaneously. 

For reference, Table [2] gives the running time of each al- 
gorithm. Note that the GM. Setup, KGC. Setup, and Join al- 
gorithms can be run offline, and the UserKeyGen algorithm 
can be run separately against the session. Moreover, we 
ignore the RelayRequest and RelayContent algorithms since 
these (run by Proxy) just relay the communication, and are 
run independently against any cryptographic operations. 



Table 2: Running Time (algorithms) 



Algorithm 


Time(msec) 


Entity 


GM. Setup 


105.712 


GM 


KGC. Setup 


102.883 


KGC 


Join 


109.036 


User-GM 


UserKeyGen 


102.958 


User-KGC 


SendRequest 


125.069 


User 


ValidityCheck 


199.247 


SP 


SendContent 


198.636 


SP 


GetContent 


101.158 


User 



The dominant factor for User is the SendRequest algorithm 
which computes a group signature. Note that this procedure 
can also be run offline by assuming that the User chooses 
TempID and computes a group signature before starting a 
session. Then, the total running time of one session becomes 
less than 500 msec. 

6. CONCLUSION 

The proposed protocol along with our group signature en- 
ables secure anonymous authentication. It is feasible and 
practical in terms of transaction time. Although this paper 
proved its concept, we need to consider practical deployment 
over the Internet. Indeed, the protocol requires a proxy that 
assists secure, anonymous, and authenticated communica- 
tion. Though various types of proxy may exist, including 
Tor routers, we need to consider and verify the adaptability 
of our protocol to the current infrastructure. On the other 
hand, assorted anonymous communication systems [5] 1151 
119] have risks of being used by malicious parties. One rea- 
son for that is their inability to authenticate users. Properly 
applying our protocol may enable these systems to be prop- 
erly used. Through this work, we wish to facilitate secure, 
anonymous, and authenticated communication over the In- 
ternet. 
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